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REMARKS 

This amendment is submitted in response to the Examiner's Action dated November 16, 
2004, Applicant has amended several claims to clarify key features of the invention. No new 
matter has been added, and the amendments place the claims in better condition for allowance. 
Applicant respectfully requests entry of the amendments to the claims. The 
discussion/arguments provided below reference the claims in their amended form. 

CLAIMS REJECTIONS UNDER 35 ILS.C. S 103 

In section 2 of the present Office Action, Claims 1-14 and 20-36 are rejected under 35 
U.S-C. § 103(a) as being unpatentable over Robertson, et al (U.S. Patent No. 6,594,799) in view 
of Dole (U.S. Patent No. 63634,008). Further, in section 3 of the present Office Action, Claims 
15-19 are rejected under 35 U,S.C. § 103(a) as being unpatentable over Robertson in view of 
Dole and further in view of Dragulev, et al (U.S. Publication No. 2001/0037407). 

None of the above references or the combinations of references suggests the subject 
matter of Applicant's claims. Applicant first identifies several of the general deficiencies found 
within the references and combinations thereof as they apply to Applicants * claimed invention. 
Then, Applicants present arguments within delineated sections addressing the rejections of 
specific claims. The clarifications or examples given for claim elements/features are provided 
solely to clear up any misunderstandirig/mischaracterizations that Examiner may have with 
respect to Applicant* s invention and are not intended to limit the scope of the invention as 
originally filed. 

A. Applicant's Claimed Invention (& Claims 1, 28* etc>> 

Applicant's invention provides a seamless integrated design data repository (see, for 
example, Fig 7). With Applicant's invention, heterogeneous design data (informational 
structures) are compiled into a single format (syntax) and a single repository (database). 
Applicant's invention allows various design services, design tools, and designers (design 
personnel/engineers) to work from a unified interface whether local or remote (Figure 4, 5, and 
7) and have access to all the necessary design data and design rules in a single standard format 
and environment (SOCML database 406). Applicant's invention, with its associated methods 
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and utilities ensure all dispersed design data and design rules are collected, compiled and 
maintained in the central repository for each stage of design (Figure 3). 

Applicant's invention generates and compiles the data necessary for applications (both 
internal and external). Further, Applicant's system (as shown in Figure 8) identifies the tools 
and expertise required for a design task (809) and creates a task schedule and action list (819), as 
well as alternatives (825) and a detail schedule of task and resource allocations (827), 

None of the above active functions are covered by the passive interface provided by 
Robertson's system or the interfaces provided by the other references. Robertson also does not 
provide a single, unified database, as recited by Applicant's Claim 1 . 

Robertson 

Robertson provides a collection of databases (as described below) and does not provide 
or suggest providing access to a single unified virtual database. Robertson is concerned with 
catalogs of parts and information about vendors (see col 8, lines 36 - 60), which is inherently 
distinct from and not suggestive of the "design data" described by Applicants' claimed invention. 

Robertson's system acts as an aggregate point for many suppliers (Robertson - col 8, lines 
21-35) providing passive access to external data. No integration of data and no refinement are 
provided. Robertson's portal acts as an intermediary between the outside entities and the 
applications available at the portal, 

Robertson's portal, described in Figure 2 (204) serves as an interface/intermediary 
between internal and external applications (col. 7, lines 36-57). There is no mention of and no 
mechanism for any data or service transformation. There is also no mention or suggestion of 
providing an integrated and single virtual design database. The portal merely receives requests 
and passes them through. 
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Dote 

The system described by Dole serves as a methodology manager where predefined design 
tasks are completed by specific engineers and brought together for integration (coL 5, lines 10- 
41), Dole's system provides for an orderly design and test of an integrated circuit (col. 6, lines 
19-26), Thus, in contrast to Applicant's invention, Dole does not provide a virtual design 
database and/or any active collaboration. Rather Dole partitions design tasks into sub- 
methodology steps and each step is performed on a specific tool by specific designer and then 
brought together (col. 5, lines 32-45). 

At col. 12, lines 25-35, Dole describes how a designer follows a set of steps to perform 
logic synthesis, using a synthesis tool and following a predefined synthesis set of steps, mere is 
no mechanism for integration of various heterogeneous design data from different sources to 
enable such a synthesis, as is provided by Applicant's claimed invention. Dole describes an 
environment where all necessary components and tools and design files exist in the proper 
format and all is needed is to follow a set of steps to complete the synthesis. If a design 
component was completed in a different design format or design tool, it is not clear how Dole's 
environment would handle it. Applicant's system (as shown in Figures 4, 5, and 6) provides 
standard schema and methods to extract the necessary data for each design task and recompile 
and convert to the required format and make it available to the new tool or new team in a 
seamless manner. 

L Collaboration 

Applicant's invention provides design collaboration, where a design is partitioned to 
design tasks according to the available tools and skills. Different design tasks are conducted by 
different design teams (based on their registered skills and access to (or familiarity with) 
different design tools). Applicant's system maintains a knowledge-base of user expertise (816) 
and specific design task and tool expertise available (database 817), In addition, Applicant's 
system maintains a knowledge-base of expertise and clearance level required by a design (823) 
and all internal and external dependencies (821). Applicant's system then matches the right 
expert with access to the required tools and resources to the appropriate design task. 
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No such capability is described for Robertson's system. The collaboration described by 
Robertson is a passive collaboration and does not include any design task collaboration (see col. 
9 ? lines 4-14). Robertson's system collect user data for keeping track of access stats and web 
traffic patterns, application usage as well as to provide information to external suppliers (col. 9, 
lines 14 - 30). 

Further, the system and method described by Robertson does not provide collaborative 
design where design is partitioned to distinct design tasks and then each task is matched to a 
specific expert in different location or to a specific resource in different location. Robertson 
defines a system for selecting components from a menu or list via Internet to perform a design 
task as shown in the following statements (coi. 5, lines 39-42; col. 10, lines 3-10). There is no 
partitioning of design and no assignment of design tasks to individuals in different locations. 

ii. XML document versus SQCML 

Applicants system describes an XML schema -to serve as a container and exchange 
mechanism for design data description as well as the design data files and rules themselves 
(Figures 4, 5 ? 6). It appears that Applicant's use of the term XML has confused Examiner into 
thinking that a standard XML language function is being utilized, as with use of XML to create a 
document that is then passed from one device to another. However, Applicant's system provides 
a mechanism where dispersed and heterogeneous design data and design service expertise are 
converted and presented in a unified schema (SOCML) and not just a generic XML format (see 
Fig 4 - 405, 403, 406, 408, etc.). 

Robertson describes a set of independent databases that can be configured in a distributed 
fashion through secure XML tunnels (col. 8, lines 61-67). Robertson never contemplates or 
suggests the use of SOCML, which has a completely different functionality than a generic XML. 
Robertson's system would not require SOCML because Robertson teaches a different operation 
than the design operation provided by Applicants* invention. Neither Robertson nor Dole 
provides any specific XML schema, or methods on seamless integration of design data. 
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Dole uses XML to describe the methodology steps (col, 16 lines 48 - 62) and not for a 
design data representation schema. Dole describes the design methodology (list of steps and list 
of actions to be performed in each step) in XML in one or multiple XML files or HTML files (id. 
at lines 58-62). No specific XML schema and no specific standard is defined. Dole's use of 
XML to describe methodology (listed in col. 16, lines 20-30) simply uses XML to document list 
of tasks to be performed in a design. The document list neither relates to collaboration among 
various design team members nor does it involve management of design expertise or access to 
design database or utilities. 

In Figure 4 and 5 of Applicant's specification, Applicant describes methods for extracting 
the necessary design data and design attributes to provide logic synthesis and design behavioral 
synthesis. These syntheses are possible because of the central unified SOCML schema and 
repository, which is very different from adding some loosely defined scripts to define a desiga 
scenario script (methodology), as suggested by Dole. 

B. Claim Rejections 
iClaitti2 

Applicant' Access_Privilege_manager maintains a user expertise profile as well as a 
designer role profile. Based on the designer role, access to different design files, rules and tools 
are granted during the collaboration. In addition, a database of external expertise profile allows 
outsourcing of design tasks to the appropriate design teams and designers (described in page 7 
lines 1-4 of the specification). None of the above user expertise profiling is available in 
Robertsoris system. Robertson, at col. 15, lines 2-20 describes a method for gathering user 
profile such as name, ID, password, etc. However, Robertson does not include any information 
on the user expertise and the tools and utilities they axe familiar with, as is provided within 
Applicant's claimed invention and described on page 6 lines 15-22 of the specification. 

fi. maim ^ 

Applicant's Claim 3 defines methods for exchange of applications and design services 
between multiple locations by sending the request for a desiga service or request for access to a 
tool via standard protocol defined in XML format based on SOCML schema. Also, Applicant's 
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invention provides search and match methods to formally define the actual expertise and tools 
required to perform a design task and then identifies the most appropriate sources of such 
expertise and makes them available to the user. This help could come from an expert system, 
from a human expert, from a design tool, etc. 

Robertson*, at col. 27, lines 34-48 defines a user sending an email message to an expert 
and requesting help. Robertson never describes or suggests any automation and/or a standards 
service request-exchange protocol. Rather, Robertson describes a traditional one-on-one 
collaboration where a phone or email or pen and paper medium is used to define a problem to 
which an expert then responds. 

iii. Claim 4 

In addition to other features, Applicant's Claim 4 recites SOCML, which is a specific 
XML schema to define System-on-a-Chip design data and a standard for storing and transporting 
SOC specification and design data. Arguments for SOCML are provided above. Additionally, 
col. 16, lines 20-39 of Dole describes how to use XML to define a methodology, i.e. a set of 
design steps and an ordered list of tasks. This could be done in HTML, a flow chart, or plain 
English* Dole does not define a standard protocol for defining and representing a methodology, 
and his description of using XML to define methodology does not apply to SOC and does not 
offer any standards or protocol schema. 

iv. Claim 5 

Applicant's Claim 5 defines methods to implement the SOC XML schema and its 
associated methods (i.e. Java) so it can be deployed on any platform (Windows, Linux* ADC, 
Unix, etc.) and accessed via.. Internet (browser) or command line. A number of such Java 
methods are described in Figure 4 (41 1, 413, 415, 417). 

Dole, at col. 16, lines 66-67, simply describes a converter that takes multiple XML files 
and converts them to a single XML file. There is no XML schema or a standard protocol 
involved nor any platform independent methods. 
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v. Claim 6 

Applicant's Claim 6 describes a framework that allows partitioning of design into distinct 
design tasks and operations where each task or operation can be delegated (assigned, outsourced, 
contracted) to the best matched expertise and resources* In contrast, Dole describes how design 
programs can be used on computers manufactured by different companies (SUN SPARC or a 
PC) or different computer types (Laptop, workstation, etal.) (col. 4, lines 48-63). While it is true 
that design programs arid utilities can be run on SUN, Linux machine, Windows, etc., this has 
nothing to do with partitioning of design tasks or providing an environment for collaborative 
design. 

vL Claim? 

In Claim 7, Applicant describes how design data and design files can be converted to a 
format suitable for another design team. Thus, for example, if a design task is outsourced to a 
team in another country. Applicant's invention may then use the appropriate XSL style sheet and 
XSLT transformers (412) to convert the necessary design data, design rules, design files, design 
documentations (405) that would match the tools and utilities the receiving team has access to or 
formats and languages they are familiar with. 

Col- 16, lines 31-39 of Dole describes how XML can support multiple languages. 
However, Dole does not discuss converting design specification and design data from one format 
to another, which could be used to convert an English documentation to Chinese, for example. 
Dole does not mention or suggest any design data or design rule conversion and Dole also does 
not mention or suggest the use of XSL Style Sheet or XSLT transformers. 

viL Claim 8 

In Claim 8, Applicant further extends the notion of transforming design data from one 
format to another and Applicant utilizes the methods of claim 7 to transform design data to an 
industry standard (if such a tool existed). For example, if GDS is considered industry standard 
for description of an IC physical data, then appropriate XSLs and XSLTs can be defined to 
transform a number of popular formats to GDS format 
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Dole at col* 9 S lines 60-67 describes how both the library and design data used by EDA 
tools can be stored on compute server. Multiple compute servers are provided each executing a 
single EDA tooL Dole neither provides a mechanism for converting design data to a standard 
format nor does Dole advocate such an approach* Rather, Dote simply indicates that there will 
be multiple compute servers allowing different EDA tools to do their own task* 

viiL Claim 9 

Applicant's Claim 9 describes two standard mechanism (UDDI and SOAP) for 
automatically locating a required design service (described in standard SOCXML) and then, 
when such a service or utility is found, to provide secure and standard exchange between the 
provider and the requester (automatically and securely) via industry standard protocol SOAP. 
Robertson at col* 27, lines 34-48 describes how a user and an expert may communicate via email 
or via a real-time connection, so the user can describe his questions and the expert can answer 
them. Thus, while Applicant's claim is describing secure standard service and data exchange 
mechanism. Robertson is describing how a user can ask questions and receive answers via email. 
The latter function is in no way suggestive of the former. 

ix. Claim 12 

Applicant's Claim 12 describes an Access_Privilege_manager ? which maintains a 
database of who has need and authority to access what piece of design data and what tools and 
what design file. The Access_Privilege_Manager and its associated functionality are described 
in Figures 5 and 6 and linked to processes of Figure 8 (819, 823, 829 and database 817). 

Robertson at col. 15, lines 2-20 describes how information about user can be collected 
and used to allow a user to login to a system* Robertson does not deal with or suggest 
associating what tasks a user is capable of perfonning, has clearance to perform, has access to 
the necessary tools and databases to do so, etc* 

x. Claim 13 

Applicant's Claim 13 describes how a user may be authorize to access one part of design 
and not another (due to legal restrictions or technical requirements) and how a team will be able 
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to apply a design ta$k to a collection of design data but not have access to change the design data 
for example. Such complex and multi-tier access and authorizations are managed by the 
Access_Privilege_Manager (as shown in Figures 6B and 8). The communication and exchange 
among various sites as described in Figure 7A and 7B is also managed by 
' Access_Privilege_Manager. 

Robertson at coL 13, lines 17 - col. 14, line 5 describes how user infonnation is 
transmitted to a supplier so the user can complete a purchase. The transaction records are 
updated when new requests are put forth. The supplier then transmits contract information back 
to the user. What Robertson describes is a one-on-one interaction between a supplier and a 
potential customer. There is no management of layered access and conditional access to 
resources. The user is not allowed access to the tools and services on the supplier side but only to 
provide a request and make a purchase. Further, coL 15, lines 2-20, described previously, deals 
with collecting user profile and does not discuss or suggest what a user should have access to and 
what tools or services will be accepted from a user. 

xL Claim 14 

Applicant's Claim 14 describes how the framework automatically manages the access to 
various design files and design tools and services (Fig 6B)for each user, design team, service 
provider, or program based on its access privileges and access authorizations. Such a capability 
allows distributed operations as shown in Figures 7A and 7B, according to the processes of 
Figure 8. 

Robertson at col. 14, lines 14-20 describes that a user may need authorization to make a 
purchase and she can obtain such an authorization in different methods. Such a straight forward 
process does not apply to complex and hierarchical processes of integrated circuit design where a 
large number of expertise and tasks are involved along with rather complex licensing and 
contracts. A user may have access to a design file and may be authorized to perform a certain 
task but he may not be authorized to access the tools required. 
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Each of the other claims is similar to one of the foregoing claims and/or is dependent on 
one of the foregoing claims. Given the ahove reasons, it is clear that the combinations of 
references do not suggest key features of Applicant' claimed invention- One skilled in the art 
would not find Applicant's invention unpatentable over the combination of references. All 
claims are therefore allowable. 
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CONCLUSION 



Applicant has diligently responded to the Office Action by clarifying features of the 
claims and providing detailed arguments rebutting/overcoming the §103 rejections presented. 
The amendments and arguments overcome the §103 rejection, and Applicant, therefore, 
respectfully requests reconsideration of the rejection and issuance of a Notice of Allowance for 
all claims now pending. 

Applicant further requests the Examiner contact the undersigned attorney of record at 
512-343.61 16 if such would further or expedite the prosecution of the present Application. 
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